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(57) ABSTRACT 

A component-based, rapid application development (RAD) 
Java system providing visual designers (i.e., wizards) and 
methodology allowing a developer (user) to create Java 
Beans-compatible components rapidly and easily is 
described. In typical operation of the system, the user may 
generate a "bean" component by invoking a wizard-based 
interface that implements methodology for automatically 
generating and managing the bean. The user employs the 
wizard to specify information about the bean, such as the 
name of the bean, the package it will be in, and the class it 
extends from. In response to the user input, the system 
creates a bean with the name the user specified, places it in 
the user's current project, and displays the source code 
generated for the bean. The user may visually interact with 
the bean (or other existing bean) by using the visual design- 
ers to manage the bean's properties, including: adding 
properties to the bean, adding bound and constrained 
properties, modifying properties of the bean, removing 
properties from the bean, or even generate a custom property 
editor. In a similar manner, the user may proceed to use the 
visual designers to manage the bean's events, including: 
adding events, listening for events, and creating custom 
event sets. 
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DEVELOPMENT SYSTEM WITH VISUAL Java bytecodes are designed to be easy to interpret on any 

DESIGN TOOLS FOR CREATING AND machine. Bytecodes are essentially high-level, machine- 

MAINTAINING JAVA BEANS COMPONENTS independent instructions for a hypothetical or "virtual" 

machine that is implemented by the Java interpreter and 
RELATED APPLICATIONS s runtime system. The virtual machine, which is actually a 
The present application is related to and claims the benefit specification of an abstract machine for which a Java Ian- 
of priority from the following commonly-owned, W « m P de ' bvtec ] od ;> must be available for 
co-pending U.S. provisional patent application: Ser. No. ^ various hardware/software platforms on which an apph- 
60/089,799, filed Jun. 18, 1998, and entitled Development «Um, « *> run. The Java interpreter executes Java bytecode 
System wrra Visual Design Tools for Creating and 10 Meetly ° n any machine for which the interpreter and 
Maintaining Java Beans Components. The disclosure of ™ ntim , e of Java have been ported. In this manner, the 
the foregoing is hereby incorporated by reference in its same Java language bytecode runs on any platform sup- 
entirety, including any appendices or attachments thereof, ported by Java. 

for all purposes. Compiling Java into platform-neutral bytecodes is advan- 

15 tageous. Once the Java language interpreter and runtime 
COPYRIGHT NOTICE support are available on a given hardware and operating 
A portion of the disclosure of this patent document system platform, any Java language application can be 
contains material which is subject to copyright protection. executed. The bytecodes are portable since they do not 
The copyright owner has no objection to the facsimile m require a partcular pr«^r architecture, or other propn- 
reproducnon by anyone of the patent document or the patent 20 'tary hardware support. Further, the bytecodes are byte- 
disclosure as it appears in the Patent and Trademark Office ^baBga^ni^v«f^'^«K^m^ 
patent file or records, but otherwise reserves all copyright big-endian machines (e g. Intel architecture) and little- 
rights whatsoever. endian machines (e.g., Motorola architecture). Since Java 
' bytecodes are typed, each specifies the exact type of its 
BACKGROUND OF THE INVENTION « operands, thereby allowing verification that the bytecodes 

, . ,i . a „.i „, obey language constraints. All told, the interpreted bytecode 

The present invention relates generally to a development ^ * J ^ J&va ides 

environment for creaung application programs and other £ tabfli of ^ to tem on which me Java 

software and particularly to a system with methods and £ £ system y ha V e been im p, e mented. 

interfaces facilitating creation of components for use in such - n r J . 

an environment. ^ bytecodes are actually stored in "class" files. Each 

tU " . e t„*™-« nn A tu a txwm class file stores all the information for a particular Java class. 

J^St eXpl0S1VC ? u \ , f A "class" in Java is a software construct which defines 

WKle Web an ever-increasmg number of computen > of m „ & 

disparate platforms are bemg connected together. As a result, kr 

there is renewed interest m distributing software m bmary 35 P * ^ P ™ 

format which operates in th K ever-mcreasmg heterogeneous 8 ^ ^ P 

environment. In the early 1990s, a team at Sun Microsys- ruim wa *°» AUl 7 
terns developed a new language, "Java," to address the 
issues of software distribution on the Internet. Java is a 

simple, object-oriented language which supports multi- 40 p 0 in t { 

thread processing and garbage collection. Although the public double x; r instance variable •/ 

language is based on C++, a superset of C, it is much public double y; r instance variable v 

simpler. More importantly, Java programs are "compiled" * 
into a binary format that can be executed on many different 

platforms without recompilation. The language includes 45 This declaration serves as a template from which "Point" 
built-in mechanisms for verifying and executing Java "bina- objects can be instantiated. 

ries" in a controlled environment, protecting the user's Actual instantiation of an object occurs in a manner 
computer from potential viruses and security violations. similar to that found in the C++programming language. For 

A typical Java system comprises the following set of example, a variable which refers to a "Point" object can be 
interrelated technologies: a language specification; a com- 50 declared as follows: 
piler for the Java language that produces bytecodes for an 
abstract, stack-oriented machine; a virtual machine (VM) Pomt m y Pomt; 

program that interprets the bytecodes at runtime; a set of ^ instancc of a pomt 0D j ect is allocated as follows, 
class libraries; a runtime environment that includes bytecode 

verification, multi-threading, and garbage collection; sup- 55 myPoint-new Point ( ); 

porting development tools, such as a bytecode disassembler; 

and a browser (e.g., Sun's "Hot Java" browser). Here, one can now access variables of the "Point" object, 

Java is designed for creating applications that will be using familiar "dot" notation for referring to the names of 
deployed in heterogeneous networked environments. Such the variables, 
environments are characterized by a variety of hardware 60 
architectures. Further, applications in such environments my om - , 

execute atop a variety of different operating systems and myPointy-20; 
interoperate with a multitude of different programming 

language interfaces. To accommodate such diversity, the Objects communicate by sending messages to each other. 
Java compiler generates platform-neutral "bytecodes" — an 65 A recipient object responds to a message by selecting a 
architecturally neutral, intermediate format designed for particular method to execute. If one object wants another 
deploying application code efficiently to multiple platforms. object to do some work on its behalf, for instance, the first 
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object sends a message to the second object. The second mated generation of aspects of the code, even though the 

object, in response, invokes the method which is appropriate code itself has been edited. The present invention fulfills this 

for processing the message. The methods themselves, and other needs, 
therefore, define the behavior of objects instantiated from a 

class. In particular, it is an object's methods which manipu- 5 SUMMARY OF THE INVENTION 

late the object's data— its instance variables. ^ present i Dven tion provides a development system 

Further description of the Java Language environment can ^ BeansExpress™ visual designers (i.e., wizards) and 

be found in Gosling, J. et aL, The Java Language Environ- methodology allowing a developer (user) to create Java 

menu A White Paper, Sun Microsystems Computer Beans-compatible components rapidly and easily, including 

Company, October 1995, the disclosure of which is hereby 10 m cxisting Java dass md taxaiDg it ^ a Java Bean 

incorporated by reference. Further, once the user has created a "Java Bean" (i,e., 

"Visual" development environments, such as Borland's component), he or she can continue to use the BeansExpress 

JBuilder™, Borland's Delphi™, Microsoft® Visual Basic, visual desi g ners md methodology as true "two-way" tools to 

Microsoft® J++, and Powersoft's PowerBuilder™, are rap- make chaQges t0 the generated component, as 

idly becoming preferred development tools for quickly is needed> 

creating production applications, including those created r . . . ril _ . 

... / r T rr . t o T * In typical operation of the system, the user may generate 

with the Java programming language. Such environments , J * . \ . . , , j • . _r , • i 

. . • • „ t f j i . • . a bean by invoking a wizard-based inter! ace that implements 

are characterized by an integrated development environment , * r * n ** j • 

nr^r\ -j- r «•*_»/• j • \ _* methodology for automatically generatmg and managing a 

ODE) providing a form "painter" (i.e., designer), a property Jaya £ ^ ^ ^ ^ ^ 

getter/setter manager ( inspector' ), a project manager, a tool 20 a(waB(a n) Wiarf (dialog). The user employs the 

palette (with objects which the user can drag and drop on Jaya ^ ^ ^ » ^ ^ 

forms), an editor, a compiler, and a linker (which, for a Java . . .„ , . f , * . . - „ , 

. 7 4 . -j j * u A. t Trfcif\ i package it will be in, and the class it extends from. Here, the 

environment, is provided at runtime by the Java VM). In y ^ .„ . ' . . t # . , , . ' 

. \ . r 4 , user specifies the package he or she wants the bean to be part 

general operation, the user "paints objects on one or more c n * , r l4 * .„ , tl _ - , r , 

f . iL f • . * , j * , of. By default, this will be the name of the user s current 

forms, using the form painter Attributes and properties of 25 , J A ^ T ^ \ 4 «_ . . . . , 

^iLua, uoiu 6 uiv iui yaxi«vi. i-wnxiuuvvo ^ v f project. Next, the user gives the bean being created a name; 

the objects on the forms can be modified using the property £ J I, f , t , ^ j r / 

manager or inspector. In conjunction with this operation, the * e °? r ca " ^ a class , to e3 f » d V &0m a «f?^ d ? wn 

user attaches or associates program code witt, particular The "hop^town list presents a hst of convenient classes to 

. . 4 ✓ . „ r f. A : , . use for constructmg a new Java Bean. The user can use one 

objects on screen (e.g., button obiect); the editor is used to _ . . & . iL ,. . . i4 . , 

... j l - u u l « u j . i of these classes, or can click the adjacent button to display 

edit program code which has been attached to particular 30 „ . . -j j i_ *i_ * c -t ■ 

r & * a Package browser provided by the system for specifying 

L j i * * i -j j any existing Java class desired. The user chooses any 

Today, many development tools provide source code 3 . . * , . . , ui- «ah„„, 

i * tt • j* *j_ i j t remaining options desu-ed, such as checking "Allow Only 

generation functionality. Here, an individual developer may T n 6 „ r ,. zL . . . ° . a/ 

& , . . * i t « i* *• * i Java Beans' , if the user wants the system to warn when the 

use a development tool, such as an application generator, . A _ , , , t1 _ /. „ , . A T „ 

n . j . • * . . i* ^ user tries to extend a Java class that is not a valid Java Bean, 

to automatically generates source code, thus lessening the 35 „ At , 4 < * ■ j- * i *• 

, . * J ^- Fmally, the user selects an OK button to indicate completion 

drudgery of creating certain source code (particularly, boil- . - T 4 iU - . . . 

iT T\ a ... *u*i of input for the wizard. In response to the foregoing input, 

erplate source code). A pronounced limitation of such tools A t T n -*u *u Z *Z ™ 

* #u * *u tt tt tt j | j.. the system creates a Java Bean with the name the user 

is that they are one-way. Here, once the developer edits .t , 1 . 4 . , . . . . . „„ 

source code created using the automation tool, the developer f P ecified » P lac f S 11 m *? ^ f er S t ^ ent P r0 ^ and 

cannot later return to the tool for further automating gen- 40 to 5011106 codc generated for the bean. 

eration of source code (e.g., generating code for adding new Now » uscr ma V visually interact with the bean or other 

properties for objects). existing bean by using the visual designers to manage the 

This limitation does not comport with the way the devel- bcan ' s Properties, including: adding properties to the bean, 

opers create source code, however, particularly for compo- addAn S bound and constrained properties modifying prop- 

nents (e.g., Java "bean" components). Instead, for instance, 45 eities of & c bean ' removing properties from the bean, or 

a developer would typically want to add a property and then even S eQerate a Property editor. In a similar manner, 

write some code for the property, and probably test the new ^ user ma y P roceed t0 ^ ^ visual designers to manage 

property. In fact, as the development process is a highly me bean ' s events » mcludmg: adoing events, listening for 

iterative one, such a developer would likely continue adding events > ^ creating custom event sets, 

some properties and removing other properties, until just the 50 At this point where the user wants to modify the bean 

right combination is found which achieves the functionality component, the system invokes the interface to its code 

sought in the program under development. On the other generator (i.e., to "Jot"). In particular at this juncture, the 

hand, there are "visual" design tools, such as IBM Visual system reads the user's source code, to provide a list of 

Age, which let the developer develop visually (i.e., using properties, events, and methods which are in the bean. The 

automated code generation) but do not allow the developer 55 underlying source is parsed code for enumerating this infor- 

to have easy access to the actual underlying source code and, mation. Therefore, at this point, the system has looked at the 

thus, interfere with the way the developer really works. All user's source code, for determining what (e.g., properties) it 

told, with present-day development tools, the developer is already contains. This information can now be presented to 

forced to envision the "grand scheme" of the program up the user by the property (locator) engine by displaying a 

front, in order to use the tooL Since this is not a practical 60 property sheet that lists all of the properties and their 

approach, the full benefit of source code automation tools respective types, as well as corresponding attributes (e.g., 

has not been realized in existing development systems. bound or constrained) and other special data associated with 

What is needed is a system with an improved code mem. Internally, the property engine fills out a property info 

generation capability which simplifies the task of application structure and then displays a property sheet based on that 

development. In particular, what is needed is a two-way 65 structure. 

code generation tool that may be used to not only allow Now, the system is operating in interactive mode, waiting 

automated generation of code, but also allow later auto- for the user to add a new property, for instance. To add a new 
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property, the user inputs sufficient information into the the exemplary embodiments which follows is for purposes 

wizard that allows the system to populate a new property of illustration and not limitation. 

info structure. Upon the user committing the change, the tpmprat ARPHTTFrniRP 

system generates a new property info structure internally btwiiRALAKUiiJiiLiUKb 

and then writes out that change to source code . In particular, 5 ^ System Hardware 

the user request is passed from the user interface back to the . 

property engine, which emits a new property info structure. ™ e P»«t invention may be embodied on a computer 

Thfa is communicated to the code generator. Based on the ^ f ch 35 the system 100 of FIG. 1£ which includes 

contents of this new structure, the code generator writes out a P™ esso t r ™> TX™™^ ,3 ^.^puVoutput 

j - i r • -i *u controller 103, a keyboard 104, a pointing device 105 (e.g., 

new source code, accordingly. In a similar manner the 10 m ^ ^ ^ deyi Qf ^ ^ a ^ x device 

system may receive and process other user requests, such as m ^ a mass sU)rage m ( removable ^ flopp y 

a request for the component to be a source for a new event. digk? fixed ^ G?tical ^ ( mcluding CD-ROM), and the 

nDTCC nccPDiDTrnNt nc -rue hd au/tmpc Uke )- Additional input/output devices, such as a printing 

BRIEF DESCRIPTION OF THE DRAWINGS deyicc m may be provided witn thc system 100 as desired. 

FIG.lAisablockdiagramofacomputersysteminwhicb 15 As shown, the various components of the system 100 

the present invention may be embodied. communicate through a system bus 110 or similar architec- 

• ti,j. j: ^ . c ture. In a preferred embodiment, the system 100 includes an 

FIG IB is a block diagram of a software system for m& nal mmp[iteTi £ vaila ble from a vari- 

controlling the operation of the system of FIG. 1A of (i £ luding raM Corp. of Armonk, N.Y.). 

FIG . 2A is a block diagram of a Java development system. ^ 

FIG. 2B is a block diagram showing further detail of the B. System Software 

virtual machine of the Java development system of FIG. 2A. Illustrated in FIG. IB, a computer software system 150 is 

FIG. 2C is a bitmap screen shot illustrating a preferred provided for directing the operation of the computer system 

interface of a Java-based visual development system of the 100. Software system 150, which is stored in system 

present invention. 25 memory 102 and/or on disk storage 107, includes a kernel or 

FIG. 3 is a bitmap screen shot illustrating an exemplary operating system (OS) 160 and a window-based shell or 

wizard-based interface and methodology for generating a interface 180 (e.g., graphical user interface or GUI). One or 

"bean" in the system. more application programs, such as application programs 

FIG. 4 is a bitmap screen shot illustrating a Properties J7° °L ™ ndoWS ^ ppH f £ ons P r °g ram s 190, may be 
Designer interface for assisting the user with the task of 30 .transferred from storage 107 into memory 

adding a property to a bean. 102) for execution by the system mOS 160 and shell 180, 

^Jr * L . , .„ A . KT ^ as well as application software 170, 190, include an interface 

FIG. 5 is a bitmap screen shot illustrating a New Property for receivin ^ commands and data and displaying results 

dialog for assisting the user with the task of adding a ^ other useM mformation . Software system 150 also 

property to a bean. includes a visual development system 200 of the present 

FIG. 6 is a bitmap screen shot illustrating a Bean Info 35 invention for developing system and application programs. 

Designer for assisting a user with modifying Beanlnfo data ^ shown, the development system 200 includes compo- 

for a property. nents which interface with the system 100 through shell 180, 

FIG. 7 is a bitmap screen shot illustrating an Events as well as components which interface directly through OS 

Designer for assisting with the process of making one's bean 160. 

capable of sending an event object to listening components. 40 [n a pre f crrct i embodiment, operating system 160 and 

FIG. 8 is a bitmap screen shot illustrating a New Event Set shell 180 are provided by Microsoft® Windows 

dialog box for assisting with the task of specifying a new 9x/Windows NT, available from Microsoft Corporation of 

event set. Redmond, Wash. Those skilled in the art will appreciate that 
FIGS. 9-10 are bitmap screen shots illustrating a New system may be implemented in other platforms, includ- 

Property Editor dialog box for assisting with the task of 45 m Macintosh, UNIX, and the like. Development system 

creating a new property editor. 200 » on tne other hand > includes JBuilder™, available from 

11 - l'* u i -11 i *■ n * — • Inprise Corporation (formerly, Borland International, Inc.) 

FIG. 11 is a bitmap screen shot lUustratmg an Enterprise J ^ ^ Application software 170, 190 can be 
JavaBean Wizard for assisting with creation of an Enterprise ' • y ' ^^ LL - prr^^ 1 - " * > 

k ean any one of a variety of software applications, such as word 

. , , , . 50 processing, database, spreadsheet, text editors, and the like, 

FIG. 12 is a block diagram illustrating a high-level view inching those created by the development system 200. 
of a Java Bean generation (JBX) engine of the present 

invention. C. Development System 

DETAILED DESCRIPTION OF A PREFERRED ShoW ^ dct ^ *? n0 '. 2K - a / a J a dev ^0pment 

EMBODIMENT 55 svstem ™0 of the present invention includes a client 210 

which employs a virtual machine 220 for executing pro- 
The following description will focus on a preferred grams. In particular, the client 210 executes a "compiled" 
embodiment of the present invention (and certain (i.e., bytecode or pseudo-compiled) Java program 240, 
alternatives) embodied in a visual development environment which has been created by compiling a Java source code 
running on an Intel 80x86-compatible computer operating program or script 205 with a Java compiler 230. Here, the 
under an event-driven operating system, such as the 60 Java source code program 205 is an application program 
Microsoft® Windows 9x/NT environment. The present written in the Java programming language; the pseudo- 
invention, however, is not limited to any particular applica- compiled program 240, on the other hand, comprises the 
tion or any particular environment. Instead, those skilled io bytecode emitted by the compiler 230. The virtual machine 
the art will find that the system and methods of the present 220 includes a runtime interpreter (and/or just-in-time 
invention may be advantageously applied to a variety of 65 compiler) for interpreting the Java bytecode program 240. 
platforms and environments, including Macintosh, UNIX, During operation, the client 210 simply requests the virtual 
NextStep, Linux, and the like. Therefore, the description of machine 220 to execute a particular Java compiled program. 
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As shown in FIG. 2B, the virtual machine 220 comprises 
a class loader 221, a bytecode verifier 222, a bytecode 
interpreter 223, and runtime support libraries 224. The class 
loader 221 is responsible for unpacking the class file which 
has been requested by a client. Specifically, the loader will 
unpack different sections of a file and instantiate in-memory 
corresponding data structures. The class loader will invoke 
itself recursively for loading any superclasses of the current 
class which is being unpacked. 

The bytecode verifier 222 verifies the bytecode as fol- 
lows. First, it checks whether the class has the correct access 
level. Since the class will access other classes for invoking 
their methods, the bytecode verifier must confirm that appro- 
priate access is in place. Additionally, the bytecode verifier 
confirms that the bytecode which comprises the methods is 
not itself corrupt. In this regard, the bytecode verifier 
confirms that the bytecode does not change the state of the 
virtual machine (e.g., by manipulating pointers). 

Once the bytecode has been verified, a "class initializer" 
method is executed. It serves, in effect, as a constructor for 
the class. The initializer is not a constructor in the sense that 
it is used to construct an instance of a class — an object. The 
class initializer, in contrast, initializes the static variables of 
the class. These comprise the variables which are present 
only once (Le., only one instance), for all objects of the class. 

Runtime support libraries 224 comprise functions which 
provide runtime support to the virtual machine, including 
memory management, synchronization, type checking, and 
interface invocation. At the client, runtime support libraries 
224 are included as part of the virtual machine; the libraries 
are not downloaded with the Java application. The bytecode 
which is executed repeatedly calls into the runtime support 
libraries 224, for invoking various Java runtime functions. 

D. General Development Interface 

The present invention is embodied in a component-based, 
rapid application development (RAD) Java system 
(commercially embodied as JBuilder™). Many of the tra- 
ditional requirements of programming, particularly for GUI 
applications, are handled automatically by the system for the 
programmer. 

FIG. 2C illustrates a preferred interface of the Java-based 
visual development or programming environment 260 pro- 
vided by the system. As shown, the programming environ- 
ment 260 comprises a main window 261. The main window 
261 itself comprises main menu bar 262, tool bar (buttons) 
263, and component palette 264. 

Main menu bar 262 lists user-selectable commands, in a 
conventional manner. The menu bar 262 is where the user 
selects menu commands. The following provides brief 
descriptions of menu commands. 



-continued 



Menu 



Commands for 



File menu 



Edit menu 



Search menu 



View menu 



Build menu 
Run menu 



Creating, opening, closing, renaming and saving files 
and projects; removing files from projects; configuring 
printers; printing files. 

Copying, pasting, deleting and selecting text; 
undoing and redoing actions. 

Finding and replacing text; searching fortext incremental- 
ly and by line number; searching for text across a 
source path; searching for a symbol. 
Viewing Debugger windows, a new AppBrowser, the 
next or previous error message, the tool bar or 
the Component Palette. 
Making or building the selected node. 
Running the application or applet; stepping over or 
tracing into code; running to the end of a selected 



10 



15 



20 



25 



30 



45 



Commands for 



method; pausing the program; setting watches or 

breakpoints; inspecting, evaluating and modifying. 
Wizards menu Running utility wizards for tasks such as implementing 

an interface, overriding a method, bundling resources, 

and wrapping an applet 
Tools menu Displaying the Environment Options dialog; invoking 

the Windows Notepad and Calculator and other 

internal tools. 

Help menu Displaying documentation, such as the Help system, 
a Beans Exp ress tutorial for creating Java Bean 
components, the JDK API Reference, and the JBCL 
API Reference. Also for viewing Online web site in the 
user's default web browser, loading the Welcome 
project for experimenting, and seeing information 
about this release of product. 



Working in conjunction with the main menu, tool bar 263 
provides the user with shortcuts to the most common com- 
mands from the main menu for commonly performed tasks, 
such as opening and saving a project; creating a new 
application; building, compiling and debugging; undoing an 
action; and searching and replacing text. The tool bar is 
configurable by the user for including icons for most of the 
menu commands. In an exemplary embodiment, the follow- 
ing are provided. 



Button 



Commands for 



FflejOpen 
Filejaose 
FilejSave File 
Filejsave Project 

35 EditjUndo 



Edit|Redo 

Search|Find 

Search|Replace 



40 



Search] Search 
ScarchjBrowse 

Run] Run 
RunjDebug 

BuildjMake 



50 



Build|Rebuild 



55 



Opens a project, file, or package. 
Closes the active window. 
Saves the active file. 

Saves the current project and all changed files that 

are shown in the system's project tree. 

Reinserts any characters deleted, deletes any characters 

inserted, replaces any characters the user overwrites, or 

moves the cursor back to its prior position 

Reverses the effects of an Undo. 

Searches for text within the active file. 

Replaces specified text with other specified 

text in the current file. 

Again Finds the next occurrence of a search 

string in the current file. 

Loads the specified class into the App Browser. 

The class must be on the imports path of the 

current file. 

Compiles and runs the application using the startup 
parameters in the Parameters dialog box. 
Compiles the program and runs it in the Debugger 
using the startup parameters in the Parameters 
dialog box. 

Compiles any .java files within the selected node 
that have outdated or nonexistent .class files. 
Also compiles any of the node's imported files 
that the node depends on which have outdated 
or nonexistent .class files 

Compiles all .java files within the selected node, 
regardless of whether their .class files are outdated. 
Also compiles the imported files upon which the node 
depends, regardless of whether their .class 
files are outdated. 



By placing the mouse pointer over the tool bar buttons, 
without clicking, the user can view flyover labels of the 
60 buttons. 

The component palette 264 displays components avail- 
able in the JBuilder component library. Components are the 
elements which a user employs to build his or her applica- 
tions. They include all of the visible parts of an application, 
65 such as dialog boxes and buttons, as well as those which are 
not visible while the application is running (e.g., system 
timers). In the programming environment 260, components 
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are grouped functionally on different pages of the compo- about each particular property (e.g., name and type of 

nent palette 264, Each functional group is identified by a tab property), together with various options for the property, 

member, which includes a label indicating the particular such as whether the user desires a getter and a setter method 

nature of the group. The palette can incorporate user-created to access the property. In response to this input, the system 

custom controls, which the user installs onto the palette. 5 emits source code for the component. In contrast to existing 

Additionally, the user can install third-party components. systems, however, the system of the present invention allows 

In the currently-preferred embodiment, the present inven- the source code to be modified, thereby providing a two-way 

tion is implemented in a Java-based development system, tool for creating and managing a Java bean component. 

such as JBuilder™ 2 (available from Inprise Corporation of _ _ , 17 . . TT , _ . 

o , w n n i-r\ • , , , „ n B. BeansExpress Wizard User Interface and 

Scotts Valley, Calif.), operating on an appropriately- 10 y Op erat i on 

programmed computer. Description of JBuilder™ is pro- ^ 

vided by the following manuals (available from Inprise The present invention provides a development system 

Corporation of Scotts Valley, Calif.): JBuilder User's Guide with BeansExpress™ visual designers (i.e., wizards) and 

(Part No. JBA1310WW21770), JBuilder Programmer's methodology allowing the developer (user) to create Java 

Guide (Part No. JBA1310WW21771), and Java Beans Com- is Beans-compatible components rapidly and easily, including 

ponent Library Reference Volumes 1 & 2 (Part Nos. taking an existing Java class and turning it into a Java Bean. 

JBA1310WW21772 and JBA1310WW21773). The disclo- Further, once the user has created a "Java Bean" (i.e., 

sures of the foregoing are hereby incorporated by reference. component), he or she can continue to use the BeansExpress 

Further description of the development system may be visual designers and methodology as true "two-way" tools to 

found, for example, in commonly-owned U.S. patent appli- 20 make further changes to the generated component, as 

cation Ser. No. 08/992,434, filed Dec. 17, 1 997, and entitled, needed. 

Development System with Application Browser User 1. "Java Bean" Components 

Interface. The complete disclosure of the foregoing appli- At the outset, it is helpful to briefly explain what a "Java 

cation is hereby incorporated by reference. Bean" (also "JavaBean" or simply, "bean") is. A Java Bean 

The following description will focus on those features of 25 is a collection of one or more Java classes, often bundled 

the development system 200 which are helpful for under- into a single JAR (Java Archive) file, that serves as a 

standing system and methods of the present invention for self-contained, reusable component. A Java Bean can be a 

implementing visual design tools for creating and maintain- discrete component used in building a user interface, or a 

ing "beans" — that is, Java Beans components. non-UI component such as a data module or computation 

30 engine. At its simplest, a Java Bean is a public Java class that 

VISUAL DESIGN TOOLS FOR CREATING AND has a const ructor with no parameters. Java Beans usually 

MAINTAINING JAVA BEANS COMPONENTS havc p ropcrtics> methods, and events that follow certain 

A General naming conventions (also known as "design patterns"). 

Like other types of components, Java Beans are reusable 
The Java Bean (or JavaBean) architecture or component 35 pieces of code that can be updated with minimal impact on 

model, as defined by Sun Microsystems, provides standard ^ c testing of the program they become a part of. Java Beans 

design patterns for declaring properties, methods, and events ^ ave gome unique advantages over other components, how- 

(PME) for components. It provides a defined model of how ever They are pure Java, cross-platform components. They 

a reusable component in Java should be packaged, so that can t, e installed on the IDE (e.g., JBuilder) Component 
the component could be freely used in any Java development 40 palette and used in the construction of one's program, or 

environment. This allows users to use "bean" components in th ev can t, e used in other application builder tools for Java. 

Java-compliant development environments, such as They can be deployed in JAR files. 

JBuilder or Symantec Visual Caf6. Suppose, for instance, 2. Generating a Bean Class 

one had a "customer ID" property, which comprised a data As illustrated in FIG. 3, an exemplary wizard-based 
type of type string. In such a case, a "getter" function would 45 interface and methodology for generating a bean class in the 

be defined as "get customer ID" that took no arguments and system 200 is as follows. First, the user invokes a Java Bean 

returned a result of type string; a "setter" function would be (JavaBean) Wizard (dialog) 300 by selecting Choose Filel- 

defined as "set customer ID" that took a string argument and New to display an "Object Gallery," and selecting (e.g., 

returned no result (i.e., type void). Internally, customer ID is double-clicking) a Java Bean icon to start the Java Bean 
treated as a property. 50 Wizard. The user employs the Java Bean Wizard 300 to 

In order to support this level of functionality, the Sun Java specify the name of the bean, the package it will be in, and 

Bean model specifies a set of design patterns of how the class it extends from. Specifically within the Java Bean 

component should be coded (i.e., structured in source code). Wizard, the user proceeds as follows. The user specifies the 

Since the component is used within a development package he or she wants the bean to be part of, in Package 
environment, "bean info" (i.e., information) is provided as a 55 input field 310. By default, this will be the name of the user's 

meta-data companion to a Java bean. For instance, if one had current project. Next, the user gives the bean being created 

an "account balance" Java bean, there would also exist an a name at Name input field 320. By using the Base Class to 

"account balance" Java bean info class. The particular host Inherit From drop-down list 330, the user can choose a class 

development tool could load this information for determin- to extend. The drop-down list presents a list of convenient 
ing all the properties and all the events in the bean, and other 60 classes to use for constructing a new Java Bean. The user can 

related meta-data. Most importantly, the bean info describes use one of these classes, or can click the adjacent button to 

which properties are going to be exposed (to the developer display a Package browser provided by the system for 

user of the host development tool). specifying any existing Java class desired. By checking the 

The present invention provides a wizard-based tool which Show Only Core JDK (I.e., Java Development Kit) and Java 
automatically generates code to define property setters and 65 Swing Classes option 333 below the list 330, the user can 

getters, accessor methods, event listener and registration constrain the system to only display core JDK and Java 

mechanisms, and the like. In use, the user enters information Swing components in the drop-down list. 
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Now, the user chooses the remaining options desired; 
none of them are required. The user checks Allow Only Java 
Beans 335 if the user wants the system to warn when the user 
tries to extend a Java class that is not a valid Java Bean. The 
user checks Generate Sample Property 341 if he or she wants 
the system to add a property called "sample" to the bean. 
This option allows the user to see how the system generates 
the required code for a property. The user can remove this 
property later, or make it an actual property that the bean can 
use. The user checks Generate Main Function 343 if he or 
she wants the system to place a main( ) function within the 
bean so it can be used as the starting point of the Java 
program. Finally, the user selects OK button 351 to indicate 
completion of input for the wizard. Alternatively, the user 
can cancel the operation, by selecting Cancel button 353. 

In response to the foregoing input, the system creates a 
Java Bean with the name the user specified, places it in the 
user's current project, and displays the source code gener- 
ated for the bean. The following is exemplary code gener- 
ated for the settings shown for the settings selected for 
Wizard dialog 300. 



package beans; 
import java.awt.*; 

import boriand.jbcl.view.BearjPaael; 
public class BeanieBaby extends BeanPanel { 
BordeiLayout boiderLayoutl - new Bord«Layout(); 
public BeanteBabyO { 
try { 
jblnitO; 

} 

catch (Exception e) { 
e.printStackTraceO; 

} 

} . 

void jblnitO throws Exception ( 
this -se£Layout(boiderLa youtl); 

} 

} 



Note that the system named the bean (as the user specified) 
and extended the designated class. Furthermore, the class is 
declared as public; also, it has a parameterless constructor. 
Even in this early state of development, the class is a valid 
Java Bean. As described below, however, the system pro- 
vides visual designers and additional methodology for 
allowing the user to further customize the bean. 
3. Adding Properties to the Bean 

Properties define the attributes the bean has. For example, 
the background property describes the color of the back- 
ground for the component. Java Beans properties usually 
have both read and write access methods, also known as a 
"getter" (reader) and a "setter'' (writer), respectively. A 
getter method returns the current value of the property; a 
setter method sets the property to a new value. 

As illustrated in FIG. 4, the system 200 provides a 
Properties Designer interface 450 for assisting the user with 
the task of adding a property to the bean. The user proceeds 
as follows. From the AppBrowser interface 400, the user 
invokes the Properties Designer by selecting the bean com- 
ponent (at 411) in the Navigation pane 410 and clicking the 
Bean tab 421 to display the BeansExpress designers. From 
there, the user can select a Properties tab 423 to display the 
Properties Designer 450. 

The user may now proceed to add a property as follows. 
First, the user selects the Add Property button 431. A New 
Property dialog 500 appears, as shown in FIG. 5. The user 
specifies the name of the property in the Property Name 
input field 511, and then specifies a type in the Type input 
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field 513. The user can enter one of the Java types or use the 
Package browser to select any object type, including other 
Java Beans. By checking the Getter and Setter check boxes 
515, the user can indicate that the system should generate the 

5 methods to both gel and set the property value. If the user 
wants to make a property read-only, the user "unchecks" the 
Setter check box. The Display Name and Short Description 
are filled in automatically with default values. After entering 
desired input values, the user selects OK button 521 to 

10 indicate completion of input for the designer. 

In response, the system generates the necessary code for 
the property and adds the property to the Properties Designer 
grid. The user can view the read and write access methods 
added to the IDE's Component TYee for the bean by clicking 

15 the Source tab (shown in FIG. 4), The following is exem- 
plary code generated for the settings shown for the dialog 
500. 



20 

package beans; 
import java.awt*; 

import borland.jbcl.view.BeanPanel; 

public class BeanieBaby extends BeanPanel { 

BordeiLayout boiderLayoutl ■* new BorderLayout( ); 
private float price; // Added a private price field 

25 public BeaoieBaby( ) { 
try { 

jbmitQ; 

} 

catch (Exception e) { 
e.printStackTrace( ); 

30 } 
} 

void jblnit( ) throws Exception( 
this.setLayout(borderLayoutl); 

public void setPricc(float newPrice) { 
35 // Added a method to change the price value 

price - newPrice; 

public float gctPrice( ) { 

// Added a method to obtain the price value 
retum price; 



As shown, the system automatically added a private price 
field to the BeanieBaby class. The price field holds the value 
45 of the property. Usually a property field should be declared 
as private so that only the getter and setter methods can 
access the field. The system also generated a setprice( ) 
method (i.e., writer) that can change the value of the new 
field, and generated a getPrice( ) method (i.e., reader) that 
50 can get the current value of the field. When the bean is 
installed on system's Component Palette and the user drops 
the bean on the UI Designer, the price property will appear 
in the Component Inspector so that the user can modify its 
value. All the code to get and set the price property is in 
55 place. 

4. Modifying a Property 

Once the user has added a property to the bean, he or she 
can modify it at any time with the Properties Designer. To 
modify a property, the user proceeds as follows. First, the 
60 user selects the bean using the Navigation pane. The user 
clicks the Bean tab to display the BeansExpress designers. 
Then, the user clicks the Properties tab and selects any of the 
fields in the Properties Designer grid. Now, the user can 
make any desired changes. For example, the user can change 
65 the type of the property by entering another type. The system 
reflects the changes made in the Properties Designer in the 
source code of the bean. In a complimentary manner, the 
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user can also make changes directly in the source code and 
the BeansExpress designers will automatically reflect the 
changes (if the changes have been made correctly). 

5. Removing a Property 

To remove a property from the bean, the user selects the 5 
bean that contains the property in the Navigation pane. The 
user clicks the Bean tab to display the BeansExpress design- 
ers. Then, the user clicks the Properties tab, and selects the 
property desired to be removed in the Properties Designer 
grid. Finally, the user clicks "Remove Property" (illustrated 10 
in FIG. 4). In response to the input, the system automatically 
removes the property field and its access methods from the 
source code. This action can be confirmed by the user by 
clicking the Source tab. 

6. Adding Bound and Constrained Properties 15 
The BeansExpress wizard can generate the necessary 

code to create bound and constrained properties. To add a 
bound or constrained property, the user proceeds as follows. 
First, from the Properties Designer, the user clicks the Add 
Property button to display the New Property dialog box. 20 
Here, the user specifies a property name and type. A Binding 
drop-down list is provided to specify the property as bound 
or constrained. After completion of input, the user closes the 
dialog by selecting OIC 

If the property the user added is a bound property, the 25 
system adds the private property field to the class and 
generates its read and write methods. It also instantiates an 
instance of the PropertyChangeSupport class. For example, 
the following is the code added for a bound property called 
aUTiedUp. 30 



public class BeanieBaby extends BeanPane) { 
//... 

private String aHTledup; 

private transient PropertyChangeSupport propertyChangelisteners 

» new PropertyChangeSupport (this); 
//... 

public void setAllHedUp (String newAllTiedUp) { 
String oldAUHedUp ■ airfiedup; 

alJTiedup » newAllTiedUp; 40 
propertyChangeListcners.fiTcPropertyChange("aUTledUp", 
oldAHTSedUp, newAllTiedUp); 

} 

public String getAlTTiedUp( ) { 
return allTiedTJp; 

} 45 

} 



Note that the setAllTiedUp( ) method includes the code to 
notify all listening components of changes in the property 
value. The system also generates the event-listener registra- 50 
tion methods that are called by listening components that 
want to be notified when the property value of allTiedUp 
changes, such as the following. 
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Hie code the system generates for a constrained property is 
similar except the listeners have the opportunity to reject the 
change in property value. 
7. Creating a Beanlnfo Class 

The user can customize how his or her bean appears in 
visual tools, such as JBuilder, using a Beanlnfo class. For 
example, the user might want to hide a few properties so 
they do not appear in the system's Component Inspector. 
Such properties can still be accessed programmatically, but 
users (particularly, other developers) cannot change their 
values at design time. Beanlnfo classes are optional. The 
user can use the BeansExpress wizard to generate a Bean- 
Info class automatically to customize one's bean. 

The user can specify Beanlnfo data for a property when 
the user uses the New Property dialog box (FIG. 5). To hide 
a property so it does not appear in visual design tools such 
as the system's Component Inspector, the user leaves the 
Expose through Beanlnfo option unchecked. To provide a 
localized display name for the property, the user enters the 
property name desired to be used in the Display Name field. 
To provide a short description of this property, the user 
enters the description in the Short Description field. The 
system displays this text as a tool tip in the Component 
Inspector for this property. If the user has created a property 
editor that can edit this field, the user specifies the property 
editor in the Editor field. The Editor field displays all editors 
in scope that match the given property type. 

The Beanlnfo Designer 600, illustrated in FIG. 6, pro- 
vides a way to modify Beanlnfo data for a property, includ- 
ing letting the user specify me icon(s) desired to be used to 
represent one's bean in an application builder such as the 
JBuilder; it also generates the Beanlnfo class automatically. 
The Beanlnfo Designer displays all the properties (at 610) 
the user has added to his or her bean. If the user changes his 
or her mind about the Beanlnfo data entered for a property, 
he or she can edit one or more of these fields in the grid. 
Only the name of the property cannot be changed. To 
provide an image to use as an icon to represent one's bean, 
specify one or more images in the Icons boxes. The Icons 
boxes let the user specify different icons to use for both color 
and mono environments. If the super-class of the user's bean 
has a Beanlnfo class and the user wants its Beanlnfo data 
exposed in the Beanlnfo class for one's bean, the user 
checks the Expose Superclass Beanlnfo check box 620, The 
generated code will now include a getAdditionalBeanInfo( ) 
method that returns the Beanlnfo data of the class the user's 
bean extends. 

To generate a Beanlnfo class for the user's bean, the user 
clicks the Generate Bean Info button 630. In response, the 
system creates a Beanlnfo class for the user, with the class 
appearing in the Navigation pane. To see the generated code, 
the user selects the new Beanlnfo class in the Navigation 
pane and the source code appears. 



public synchronized void 

rernovePropertyCbAngeUstener(PropertyChangelifitener listener) { 

propertyChangeListeners.removePropertyChangeListener (listener); 

11,3 public synchronized void addPropertyChangelistenerfPropertyChangeListener 
listener) { 

propcrtyChaogcIJsteneis.aoWrcpcrtyCliangeListcncrQistener); 



65 
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package myBeans; 
import java.awt.*; 

import borland.jbcl.view.BeanPanel; 
import java.awtevent. *; 
import java.util.*; 

public class BeanieBaby extends Beampanel { 
public BeanieBaby( ) { 
} 

private transient Vector keyListeners; 

public synchronized void addKeylistener(KeyListener 1) { 

Vector v - keyListeners ~ null ? new Vector(2) : (Vector) 
keyListeners.clone ( ); 

if (Iv.contains(l)) { 
v.addElement(l); 
keyListeners - v; 



} 



} 
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The user can Later modify a Beanlnfo class, if desired. To 
change the Beanlnfo class for the bean with BeansExpress, 
the user proceeds as follows. First, the user selects the bean 
in the Navigation pane, and then clicks the Beanlnfo tab to 
display the Beanlnfo Designer. Now, the user can make 5 
changes in the grid, and then click the Generate Bean Info 
button again. The user is warned that the action will result 
in overwriting of the existing Beanlnfo class. If the user 
chooses OK, the class is overwritten with the new Beanlnfo 
data. io 
8. Adding Events to the Bean Component 

A Java Bean can generate (or fire) events, sending an 
event object to a listening object, and can listen for events 
and respond to them when they occur. The BeansExpress 
wizard can generate the code that makes the user's bean 15 
capable of doing one or both of these. 

The process of making one's bean capable of sending an 
event object to listening components is facilitated by use of 
an Events Designer 700, illustrated in FIG. 7. After selecting 
the bean in the Navigation pane, the user clicks the Bean tab 
to display the BeansExpress designers. Upon the user click- 
ing the Events tab, the system displays the Events Designer 
700. Now, the user selects the events he or she wants the 
bean capable of firing in the left window, shown at 710. In 
response, the Events Designer adds the event-registration 
methods to the user's bean. These methods are called by 
components that want to be notified when these types of 
events occur. For example, if the user selects Key events at 
window 710, the following methods are added to the bean. 

30 



protected void fi-reKeyTyped(Kcy Event e) { 
if (keyListeners != null) { 
Vector listeners = keyListeners; 
int count = listeners .size(); 
for (int i = 0; i < count; i++) 



20 



25 



40 



45 



When a component wants to be notified of a key event 
occurring in the bean, it calls the addKeyListener( ) method 
of the bean and that component is added as an element in 
KeyListeners. When a key event occurs in the bean, all 
listening components stored in KeyListeners are notified. 
The class also generates fire<event>methods that send an 
event to all registered listeners. One such event is generated 
for each method in the Listener's interface. For example, the 
KeyListener interface has three methods: keyiyped( ), 
keypressed( ), and keyReleased( ). In response, the Events 
Designer adds the following three fire <event> methods to the 
bean class. 
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-continued 



} 



((KeyListener) hstencre.e]ementAt(i)).kDy'iypcd(e); 



} 

protected void njeKeyPresscd(KeyEvent e) { 
if (keyListeners 1= mill) { 

Vector listeners - keyListeners; 
int count = Iisteners.size0; 
for (int i - 0; i < count; i++) 
(KeyListener) listeners. elementAt(i)) .keyPressed(e); 

} 

} 

protected void fireKeyReleased(KeyEvent e) { 
if (keyListeners !«»null) { 
Vector listeners - keyListeners; 
int count » Usteners.sizeO; 
for (int i » 0; i < count; i++) 
((KeyListener) listeners.elementAt(i)).keyReieased(e); 
} 

} 

Once the user has made the bean capable of generating 
events, those events will appear in the system's Component 
Inspector when the user drops the bean on the UI Designer. 
9, Listening for Events 

The user can also make the bean a listener for events that 
occur in other components. To make the bean a listener, the 
user selects one of the event types to listen for in the Events 
Designer. As soon as the user checks one of the event types, 
the Events Designer implements the associated listener 
interface in the Bean. For example, if the user checked 
java.awt.event.KeyListener, the phrase implements KeyLis- 
tener is added to the declaration of the bean and the 
KeyPressed( ), KeyReleased( ), and KeyTyped( ) methods 
are implemented with empty bodies. For instance, the fol- 
lowing is a bean that includes the generated code to imple- 
ment the KeyListener interface. 



35 



package myBeans; 

import java.awt.*; 

import com.sun.java.swingJPatiel; 

import java.awt event*; 

public class JellyBean extends JPanel implements KeyListener { // 
implements KeyListener 

BorderLayout bordcrLayoutl «« new BorderLayout( ); 

public JellyBeanf ) { 
try{ 

jblnit( ); 

} 

catch (Exception e) { 

cprintStackTracc ( ); 



} 



} 
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} 



void jblnit( ) throws Exception { 
this.setLayout (borderLayoutl); 

} 

public void keyTyped(KeyEvent parml) { // Adds new method 
} 

public void keyPressed(KeyEvent parml) { // Adds new method 
} 

public void key Released(KeyE vent parml) { // Adds new method 
} 



If the bean is registered with another component as a 
listener (by calling the event-registration method of the 
component), the source component calls one of the methods 
in the listening component when that type of event occurs. 
For example, if a KeyPressed event occurs in the source 
component, the KeyPressed( ) method is called in the 
listening component. Therefore, if the user wants the com- 
ponent to respond in some way to such an event, the user 
simply writes the code that responds within the body of the 
KeyPressed( ) method, for example. 
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10. Creating a Custom Event Set 

Occasionally the user might want to create a custom event 
set to describe other events that can occur in the bean. For 
example, if the bean implements a password dialog box, the 
user might want the bean to fire an event when a user 
successfully enters the password, or to fire another event 
when the user enters the wrong password. Using the 
BeansExpress wizard, the user can create the custom event 
set that handles these situations. 

To create a custom event set, the user first selects the bean 
that contains the property in the Navigation pane. Then the 
user clicks the Bean tab to display the BeansExpress design- 
ers. After clicking the Events tab, the user clicks the Create 
Custom Event button, shown at 715 in FIG. 7. In response, 
the system displays the New Event Set dialog box, illus- 
trated at 800 in FIG. 8. Here, the user specifies the name of 
the event set in the Name edit field 811. The names of the 
event object and the event listener are generated from the 
name of the event set; they are displayed in the dialog box. 
The user selects the dataChanged item and changes it to the 
name of the first event. To add more events, the user chooses 
the Add New Event button 813 for each event and changes 
the added item to the names of the user's remaining events. 

In response to the user clicking OK, the new event set is 
added to the list of event types that can be fired in the Events 
Designer. The system generates the event object class for the 
example event set as follows. 



package myBeans; 
import java.util.*; 

public class PasswoidEvent extends EventObject { 
public PasswordEvent(Object source) { 
super(source); 

} 

} 



The system also generates the Listener interface for the 
event set. 



package myBeans; 
import java.util.*; 

public interface Password Listener extends EventListener { 
public void passwordSuccessful(PasswordEvent e); 
public void passwordFailed(PasswordEvent e); 

} 



11. Creating a Property Editor 
a. General 

A property editor is an editor for changing property values 
at design time. The user can see several different types of 
property editors in the system's Component Inspector. For 
example, for some properties, the user simply types in a 
value in the Component Inspector, and by so doing, changes 
the value of the property. This is the simplest type of 
property editor. For other properties, the user employs a 
choice menu (drop-down list) to display all the possible 
values and selects the value desired from that list. Colors and 
fonts have property editors that are actually dialog boxes 
that the user can use to set their values. The Java Beans 
Component Library supplies property editors for the primi- 
tive Java data types. When the user creates a Java Bean, he 
or she can create new property classes and editors capable of 
editing their values. The BeansExpress wizard helps the user 
create property editors that display a list of choices. 

To begin creating a property editor for a property, the user 
proceeds as follows. The user clicks or selects the Editors tab 
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in BeansExpress, and then clicks the Create Custom Editor 
button. A New Property Editor dialog box appears. There, 
the user specifies the name of the property editor in an Editor 
Name edit field. Typically, the user gives the property editor 

s the same name as the property the editor will edit with the 
word "Editor" appended. The user selects the type of editor 
desired from an Editor Type drop-down list. The appearance 
of the New Property dialog box changes depending on 
which type of editor is selected. The following illustrates 

i° how to create a property editor for different types, 
b. Creating a String List Editor 

A String List is a simple list of strings. It appears in the 
Component Inspector as a drop-down list containing the 

15 strings specified. When the user uses the list to select an 
entry, the property being edited is set to the selected value. 
To add items to a String List editor, the user first chooses 
"Add Entry" for each item desired to appear in the list. In 
each entry, the user enters the string desired to appear. FIG. 

20 9 illustrates how a resulting a New Property Editor dialog 
box 900 might appear. Upon the user choosing OK, a new 
property editor class is created. To view the generated code, 
the user selects the property editor class in the Navigation 
pane and clicks the Source tab. 

25 c. Creating a String Tag List Editor 

A property editor that is a String Tag list also presents a 
list of strings to the user in the Component Inspector. When 
the user selects one of the items, the specified Java initial- 
ization string is used to set the property. A Java initialization 

30 string is the string the system uses in the source code it 
generates for the property. To add items to a String Tag List 
editor, the user chooses "Add Entry" for each item desired 
to appear in the list. In each entry, the user enters the string 
desired to appear, together with its associated Java initial- 

35 ization string. To include a string in the list of Java initial- 
ization strings, one puts quotation marks (") before and after 
the string, as if one were entering it in source code. FIG. 10 
illustrates how a resulting New Property Editor dialog box 
1000 might appear. Upon the user choosing OK, a new 

40 property editor class is created. To view the generated code, 
the user selects the property editor class in the Navigation 
pane and clicks the Source tab. 

d. Creating a Custom Component Property Editor 

The user can also use his or her own custom component 

45 to edit the value of a property. Selecting this choice gener- 
ates a skeleton property editor that uses the custom editor 
specified to actually edit the property. To specify a custom 
component property editor, the user enters the name of the 
custom component in the Custom Editor Name box and 

50 checks a "Support paint Value( )" option if the custom editor 
is to paint itself. As before, to view the generated code, the 
user selects the property editor class in the Navigation pane 
and clicks the Source tab. 

55 12. Adding Support for Serialization 

Serializing a bean saves its state as a sequence of bytes 
that can be sent over a network or saved to a file. The 
BeansExpress wizard can add the support for serialization to 
one's class. 

60 To add support for serialization, the user selects the bean 
in the Navigation pane and clicks the Bean tab to display the 
BeansExpress designers. Now, the user clicks the General 
tab to display the General page and checks a "Support 
Serialization" option. In response, the BeansExpress wizard 

65 modifies the class so that it implements the Serializable 
interface. In particular, two methods are added to the class: 
readObject( ) and writeObject( ). 



04/14/2004, EAST Version: 1.4.1 



US 6,237,135 bi 



19 



20 



void vrateObject(ObjectOulputStrcam oos) throws IOException { 
oos.defeuKWriteObjcct ( ); 

} 

void rcadObjcct(ObjcctInputStrcam ois) throws ChssNotFoundException, 
IOException { 

ois defaultReadObject ( ); 



} 



} 



10 



The user fills in these two methods to serialize and deseri- 
alize the bean. 

13. Creating an Enterprise Java Bean 

The system provides an Enterprise Java Bean Wizard for 15 
creating Enterprise Java Beans. An Enterprise Java Bean is 
a non-visual bean that runs on a server. Enterprise Java 
Beans are described in further detail in Sun's Enterprise Java 
Beans specification, located at http://java.sun.com/products/ 
ejb/, the disclosure of which is hereby incorporated by M 
reference. 

To begin creating an Enterprise Java Bean, the user 
chooses "File|New" and then selects an Enterprise Java 
Bean Wizard icon to display the Enterprise Java Bean 
Wizard UOO, as shown in FIG. 11. The user specifies the ^ 
package the bean will be a part of, in the Package edit field. 
By default, the wizard uses the name of the current project. 
The user specifies a name for the Enterprise Java Bean in the 
Name of New Java Bean field. The user specifies the base 
class that the bean will extend in the Base Class to Inherit 3Q 
From field. If the user wants to ensure that any class selected 
is a Java Bean, he or she checks the Allow Only Java Beans 
option. Now, the user selects a Session Bean or Entity Bean 
and chooses OK. 

The Enterprise Java Bean Wizard creates a class for the 35 
user that is a valid Java Bean. Within the class are several 
methods defined with empty bodies that the user will fill in. 
The following is sample code generated for a typical Session 
bean. 



package Enterprise; 
import java.nni.*; 
import javax.ejb. *; 

public class NewSessionBeaa implements Session Bean { 
ScssionContext context; 
public NcwSessionBean( ) { 



} 

public void ejbCreatc( ) throws RemoteException, CreateException { 

public void ejbActivate( ) throws RemoteException { 

public void ejbPassivate( ) throws RemoteException { 

public void ejbRemove( ) throws RemoteException { 
} 

public void setSessionContext(SessionContext context) throws 
RemoteException { 

this, context = context; 



} 



} 
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INTERNAL OPERATION 

A. Internal Architecture 

Internally, the system provides a Java Bean generation 
(JBX) engine 1200, shown in FIG. 12, that includes a code 65 
generation wizard 1201, property (locator) engine 1202, 
interface to code generator or Java Object Toolkit ("Jot") 



1203, event engine 1204, property editor generator 1205, 
custom event generator 1206, and user interface module 
1207. In operation, the user decides he or she wants to create 
a new Java bean component. At this point, the user invokes 
the code generation wizard 1201. The code generation 
wizard 1201 gathers information about what type of bean is 
desired, such as an enterprise bean, and determines whether 
the bean includes special properties that must be treated 
specially. In response to this information, the wizard gen- 
erates a basic framework for the component, according to 
internal rules. 

From there, the user will often want to add new properties 
and, thus, will invoke the property engine (through the user 
interface). At this point (where the user wants to modify the 
component), the system invokes the interface to the code 
generator or Jot 1203. In particular at this juncture, the 
system needs to read the user's source code. The code 
generator itself provides functionality akin to the Java 
Introspector class, functioning to provide a list of properties, 
events, and methods which are in the bean. (Java Introspec- 
tor class operates at the class level only, requiring a com- 
piled class file.) The code generator parses the source code 
such that it can enumerate this information from source 
code. Therefore, at this point, the system has looked at the 
user's source code, for determining what (e.g., properties) it 
already contains. This information can now be presented to 
the user by the property (locator) engine 1202 by displaying 
a property sheet that lists all of the properties and their 
respective types, as well as corresponding attributes (e.g., 
bound or constrained) and other special data associated with 
them. Internally, the property engine 1202 fills out a property 
info structure and then displays a property sheet based on 
that structure. 

Now, the system is operating in interactive mode, waiting 
for the user to add a new property, for instance. To add a new 
property, the user inputs sufficient information into a wizard 
(UI 1207) which allows the system to populate a new 
property info structure. Upon the user committing the 
change, the system generates a new property info structure 
internally and then writes out that change to source code. In 
particular, the user request is passed from the user interface 
1207 back to the property engine 1202, which emits a new 
property info structure. This is communicated to the code 
generator, through the interface 1203. Based on the contents 
of this new structure, the code generator writes out new 
source code, accordingly. 

In a similar manner, the system may receive a user request 
for the component to be a source for a new event. This 
request is sent to the event engine 1206. The engine, in turn, 
determines what type of event has been requested, as well as 
what are the names of the corresponding functions. Based on 
this determination, the engine then determines the appropri- 
ate source code which is required for implementing the 
event. This is communicated to the code generator, through 
the code generation interface 1203. 

The custom event generator 1206 allows the user to create 
special events, ones which are not covered by standard 
events. Using the custom event editor, the user is allowed to 
define a custom event. The custom event generator, in 
response to user input at the custom event editor, generates 
appropriate new source code, in a manner similar to that 
described above for the event engine 1204. 

Operation of the property editor generator 1204 is similar 
to that described above for other user interface actions. The 
specific input here is a request by the user to create a custom 
property editor. The user does this by inputting information 
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in a user interface dialog. Depending on the choices which 
the user has selected, the property editor generator 1204 
generates an appropriate property editor which the user can 
then use. In a manner similar to that described above, the 
system operates by taking the user request and generating 
appropriate source code, accordingly. 

B. Internal Operation 

1. Invocation 

The BeansExpress Wizard is invoked by the user clicking 
on the Bean tab in the IDE (e.g., shown in FIG. 4). In other 
words, a user event occurring in the IDE triggers the process. 
When this occurs, the wizard is invoked with a project 
context This includes information about the collection of 
files, class path, class loader location, and the like, for the 
current project under development. This allows the wizard to 
determine, for instance, where a reference that occurs in a 
file may be located. The wizard is also passed the underlying 
source file itself, in turn, the system parses the source file for 
determining what classes are in the file, including the class 
corresponding to the Java bean being created. The actual 
task of parsing the source file largely consists of filling out 
various context data structures, including Jbxlnfo, 
Propertylnfo, and Eventlnfo data structures. Since the Java 
bean must be a public class, and there is only one public 
class per file, it is straightforward to determine which class 
corresponds to the Java bean. 

2. Core Classes and Data Structures 

The Jbxlnfo data structure is a high-level data structure 
(implemented itself as a Java class) that contains informa- 
tion which is global to the bean's class. The data structure 
may be defined as follows (using the Java programming 
language). 
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member is a handle indicating the currently-selected node 
(from the IDE). JotPackages is a data member referencing a 
package manager. In effect, this serves as a combination of 
class loader and interface/handle to the code generator 

5 subsystem . The code generator subsystem provides interface 
routines, for instance, for determining where a particular 
method is located in the source code. The package manager 
may be replaced with any subsystem capable of parsing the 
structure of a Java file, lie JbxMainPanel data member is a 

10 handle to the user interface (UI), allowing for the display of 
dialogs and other user interface elements. 

Next, the Jbxlnfo data structure includes general infor- 
mation about the bean, for example, the name of the bean, 
its super-class, and its package. This is followed by private 

15 arrays. The first array, propertylnfo, contains an array of 
propertylnfo objects. One is declared for each property 
present in the bean under development. Similarly, super- 
Propertylnfo holds property information from the super- 
class of the bean. This information is useful, for example, 

20 when adding a new property (and merging it into the bean). 
The superEvents array includes an array of events that are 
"sourced" in the super-class (i.e., the events that are fired by 
the super-class). The implementedinterfaces array includes 
information about which interfaces are implemented for the 

25 bean. This is useful for determining what things the bean is 
a listener for and for determining whether the bean is a 
special type of class. 

The iconNames string array is a small array of icon names 
for the Java bean, which is useful for allowing the Java bean 

30 to represent itself in the designer. This is followed by several 
private boolean data members. The nativeChangeSupported 
member indicates whether the class has already imple- 
mented "property change" and "vetoable change," which 



class Jbxlnfo // . . . 

{ 

private IdeEnvironmcnt 
private Project 
private Node 
private JotPackages 
private JbxMainpancl 
//... 

private String 
private String 
private String 
private Array 
private Array 
//... 

private Array 
private Array 
//... 

private String[ ] 

}; 

private boolean 
private boolean 
private boolean 
private boolean 
private boolean 
//.. . 

private boolean 
private boolean 
//... 



ideEnvironment; 

project; 

node; 

packageManager, 
jbxMainPanel; 

beanName; 

superName; 

packageNamc; 

propertylnfo; 

superPropertytnfo; 

superEvents; 
implementedinterfaces; 

iconNames = new String! ] { " * 



nativeChangeSupported 0 false; 
superPropeityChangeSupported - false; 
super VetoableChangeSupported - false; 
propertyChangeSupported = false; 
VetoableChangeSupported = false; 

enterpriseBean « false; 
serializabie « false; 



The IdeEnvironment data member is a handle to the IDE 
environment; it is useful for gaining information about the 
IDE, such as time stamps. Similarly, the Project data mem- 
ber is a handle to the current project and, therefore, can be 
used to gather information about the project. The Node data 



correspond to the common ways of notifying a listener that 
a property has changed. This information is recorded since 
65 it affects the code that is generated. The superProperty- 
ChangeSupported boolean indicates whether "property 
change" is already supported in the super-class. Similarly, 
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superVetoableChangeSupported whether **vetoable change" 
is already supported in the super-class. The propertyChange- 
Supported and vetoableChangeSupported members indicate 
whether "property change" and "vetoable change" are sup- 
ported in one's own class (i.e., the current bean), respec- 5 
tively. 

Finally, the enterpriseBean data member indicates 
whether the bean is an "enterprise" Java bean. An enterprise 
Java bean is one which follows additional considerations, 10 
such as residing on a server and being devoid of user 
interface. At this point, the system captures this information 
so that it may later correctly process the Java bean. The 
serializable data member indicates whether the bean can be 
streamed out — that is, whether it implements the Java I/O 
serialization specification. 

The Propertylnfo data structure, which bears a resem- 
blance to the Java property descriptor data structure 
(java.beans.PropertyDescriptor), is a structure that contains 20 
information about a given property. The data structure may 
be defined as follows. 



15 



class Propertylnfo 
{ 

boolean inherited; 
String name; 
String type; 
String readMethod; 
String writeMethod; 
boolean bound; 
boolean constrained; 
String displayName; 
String description; 
boolean exposed; 
String propertyEditorClass; 
II... 

II Housekeeping methods for reading and writing this structure. 

} 



The inherited data member indicates whether the info has 
been built from a super-class or the current particular class. 
This is helpful in generating the code. This is followed by 
name and type of data members, which are strings storing 
self-evident information about the property. Similarly, the 
read method and write method strings store the names of the 
"getter" and "setter" methods, respectively. The next data 
member, bound, is a boolean data member indicating 
whether the property is bound. This means that the property 
fires "property change events" when it is changed. Another 
boolean, constrained, is a data member indicating whether 
the property is constrained, that is, whether it fires vetoable 
change events (when another is attempting to change the 
property). 

The displayName and description are strings dealing with 
the bean info that is generated. The exposed member indi- 
cates whether in fact the property is exposed through bean 
info. If so, the display name and description provide infor- 
mation to the user about the exposed property (e.g., in a 
builder tool). Finally, the propertyEditorClass string indi- 
cates whether a special property editor exists for editing the 
class (as opposed to a default one). 

The Eventlnfo data structure is a high-level data structure 
that contains information about a given event The data 
structure may be defined as follows. 
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class Eventlnfo 

{ 

String eventSetName; 
String packageName; 
String objectName; 
String listenerName; 
boolean currentSource; 
// Thie if the component currently fires this event 
boolean cuirentlistener; 

// True if the component currently listens for this event. 



// e.g. Action 
// e.g. java.awt event 
// eg. ActionEvcnt 
// e.g. ActionLUtener 



} 



//.. 

// Housekeeping methods. 



The eventSetName data member indicates the name of the 
corresponding event set. For example, a "mouse" event set 
might include: mouse clicked, mouse released, mouse 
pressed, and so forth and so on. Similarly, the packageName 
member includes the name of the corresponding package 
that must be imported for implementing the event. The 
objectName member stores the name of the corresponding 
event object. Every Java event method takes a correspond- 
ing event object, as one of its parameters. The event object 
contains information that is specific to the event. For 
example, the event object for an "action" event includes 
information about which object fired the event. Thus, the 
event object includes important context information about 
the event. The listenerName member indicates the name of 
the listener that one would need to implement to listen for 
the event. Finally, the data structure includes two boolean 
members, currentSource and currentListener. The former 
indicates whether the component currently fires the event 
(Le., currently sources the event). The latter indicates 
whether the component currently listens for the event. 
3. Internal Methods 

The entry point for execution of the wizard is 
changeNode, a high-level method that may be implemented 
as follows. 
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// JbxContext class... 

public void changeNode(Node node) { 
if (this .node node && showing) 
return; 

45 this.node = node; 

// Look for the Jbxlnfo in the hashmap. 
Jbxlnfo info « (Jbxlnfo) views.get(node); 
// If we couldn't find it, create a new one, and add it to the 
// hashmap. 
if (info — null) { 
50 info - new Jbxlnfo 0; 

// Build Ut . . . 
JbxMainPanel JbxMainPanel - new JbxMainPanel(info); 
info.initialize£)ata(project, node); 
jbxMainPanel.refresh(true); 
views.put(node, info); 

55 > , 

else { 

info.initializcData(projcct, node); 
info.getMainPanelOjefre«h(true); 

} 

// show ui . . . 



60 



} 



As shown, the method is invoked with a Node object, which 
represents the current file in the user's project. At the outset, 
the method simply tests whether it is being invoked with a 
65 Node object that is already the current node. If so, then the 
method need not do any work and, hence, may simply return 
(to the caller). Each time the designer is invoked, the system 
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employs a Jbxlnfo data structure (described above) for the 
node. For performance reasons, the method keeps Jbxlnfo 
data structures in a quick-access hash map. If a correspond- 
ing hash entry cannot be found for the current Node object, 
the method creates a new Jbxlnfo data structure. This is 
followed by initializing the UI, passing the Jbxlnfo data 
structure as a parameter. The actual task of initializing the 
info data structure is performed by invoking initializeData 
(described in further detail below). After the data structure 
has been initialized, it can be added to the hash table, and the 
system may proceed to show the UI. 

The initializeData method itself may be implemented as 
follows. 



// Jbxlnfo class. . . 

public void initializeData (Project project, Node node) { 
Ibis.project » project; 
this.node - node; 

this.packageManager = project.getPackages ( ); 
// Get JOT file handle. . . 

JotSourceFile srcFile - ((JavaSourceNode) node).getJotSourceFile( ); 
// Housekeeping to keep us in sync. . . 
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-continued 



// ReadNode initializes the Jbxlnfo data structures. 
JbxEngine.readNode(this > project, node); 
// Build UI models to represent our data. . . 



} 



As shown, the method is invoked with the current Project 
and Node object. The method operates as follows. At the 
outset, the method saves off some of the parameter infor- 
mation into private structures. Now, the method gets the 
source file representation for the node. The source file is 
actually returned as a Jot file handle, which may be used to 
invoke various API. calls for determining information about 
the actual source file. The actual task of initializing the 
Jbxlnfo falls to a readNode method (described in further 
detail below), including initializing the propertylnfo and 
inventlnfo data structures. After this call, the initializeData 
method may proceed to build UI models to represent the 
data. 

The readNode method itself may be implemented as 
follows. 



// JbxEngine. . . 

// This method reads the first class in the source file represented by 

node 

// It stores the info into an Array of Propertylnfo objects, to be 
// retrieved later by Jbxlnfo. 

public static void readNode(JbxInfo jbxlnfo, Project project, Node node) 

{ 

// 'Various edge case checking for IDE events. . . 
//... 

JotSourceFile srcFile - ((JavaSourceNode) node).getJotSourccFile( ); 
JotQassSource jOassSource <= ((TotdassSource) 
(srcFQe.getClasses( )) [0]); 

JotMethod[ J jMethods - jaassSourcc.getDeclaredMcthods ( ); 
// Find superclass info. . . 
Class superclass = null; 
Bcanlnfo bcanlnfo «= null; 

String superName = jClassSource.getSupercIass( ) .getNamc( ); 
// Load the superclass itself to see if we can find it 

// 

try { 

superclass ° pa ckageManager.loadClass (superName, false); 
Svstem.err.prinUn(" JBX DEBUG: Loaded the Superclass: " + 
superName); 
} 

catch ( Class No LFoundException ex) { 

System-eTrprintmC JBX DEBUG: Couldn't find the Superclass: '* + 
superName); 
} 

catch (NullPointerException ex) { 

Svstem.err.printin(" JBX DEBUG: Couldn't find the Superclass: " + 
superName); 
} 

// Get the actual beanlnfo for the superclass, to use later. 
try{ 

beanlnfo - Introspector.getBeanInfo(superQass); 

catch (IntrospectionException ex) { 

System.err.printinC 4 JBX DEBUG: Couldn't get Beanlnfo for Superclass: 
" + superName); 
} 

catch (NullPointerException ex) { 

System-err-println^ JBX DEBUG: Couldn't get Beanlnfo for Superclass: 
" + superName); 
} 

// Find stuff 

readPropcrties(jbxInfo, jMethods, beanTnfb); 
readEvents (jbxlnfo, jMethods, beanlnfo); 
readlnterfacesQbxInfo, jClassSouxce. node); 
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-continued 



readSpcciaUnfofjbxInfo, superclass); 
jT)xInfo.setBeanName(JotNamcs.gctShortaassN^ ))); 

jbxInfo.sctPackagcNainc(srcFilcgctPackagc( )); 

jb]dnfo.sctStq)crNainc(]aassSource.gctSupcrclass( ).gctNamc( )); 

jbxInfo.getPackageManagei( ).release(srcFile); 
} 

10 

This method, which is a workhorse routine, is invoked with load that super-class and invoke the Java Introspector 

the Jbxlnfo data structure to be filled out, together with the (utility) to uncover the property descriptors that came from 

current project and node. It operates as follows. At the the super-class. Specifically, the method first loads the 

outset, it reads the first class in the source file; this is the super-class and then the beanlnfo for the super-class. The 

class which is being designed (i.e., the bean). It stores the 15 beanlnfo is itself information allowing a class to describes 

info into an array of Propertylnfo objects, to be retrieved itself to a builder tool. It includes, for example, information 

later by Jbxlnfo. The method now invokes API calls, for about properties and methods of the class, as well as events 

determining specific information about the source file. The which the class listens for. To this end, beanlnfo includes 

call to geUotSourceFile gets the source rile representation. property descriptors, method descriptors, and event descrip- 

The call to getClasses returns the class source,jClassSource, 20 tors. 

which is the source for one particular class in the source file. After getting the actual super-class and its beanlnfo, the 

This is the class of the bean which is being designed. The method proceeds to find out about properties, events, 

call to getDeclaredMethods returns jmethods, which is an interfaces, and any special information for the class. This is 

array of methods that are implemented in the class. This done by invoking the Java readProperties, readEvents, 

includes, for instance, the name, type, and parameters for the 25 readinterfaces, and readSpeciallnfo API calls. The readProp- 

methods. erties call finds out about properties in the super-class and in 

Now, the readNode method proceeds to find the bean me bean itself In particular, this call, which fills out the two 

super-class information. The super-class itself is typically previously-mentioned property arrays (Propertylnfo and 

already compiled. Therefore, at this point, the method may superPropertylnfo), may be implemented as follows. 



// Find out what properties are declared in the superclass, and what 
properties 

// are declared in the bean, itseif. 

private static void readProperties(JbxInfo jbxlnfo, JofcMethodf ] jMethods, 
Beanlnfo beanlnfo) { 

// First, fill the superProperty[nfo array with the properties that 

exist 

// in the superclass. 

Array superPropertylnfo - new Array( ); 
PtopertyDcscriptoif ] pds » null; 
if (beanlnfo l» null) { 
try{ 

pds - beanlnfo .getPropertyDescriptors ( ); 

catch (Exception ex) { 

if (ex instanceof ClassNotFoundException) { 
ex pnntStackTracc( ); 

} 

} 

} 

if (pds I- null) { 

for (int i « 0; i < pdslength; i++) { 

Property fnfo proplnfo - new PropertyInfo( ); 
PropertyDescriptor pd = pds[i]; 
if (pd — null) { 

Systern.err.println(" JBX DEBUG: Skipping property: 
PropertyDescriptor is nuH"); 

continue; 

} 

else if (pd.getPropertyrype( ) null) { 

System.err.println( M JBX DEBUG: Skipping property: " + 
pdgetName( ) + u , type is null (indexed property?)"); 
continue; 

} 

propInfo.inherited « true; 
pTopInfo.name = pd.gctName( ); 
proplnfctype - pd.getPropertyiype( ).getiName( ); 
String packageName - 
JotNames.getPackageFromFull ClassName(propInfo .type) ; 

if (packageName !» null && packagcName.cqualsC*java.lang")) 

proplnfo. type « JotNames.getShoitaassName(propInfo.tvpe); 
piopInfareadMethod ** pdgetReadMethod( ) != null ? 
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pdgctReadMethod{ ).gctName( ) : aull; 

proplnfo. writeMethod - pd.getWriteMethod( ) !«* null ? 
pdgetWriteMethod( ).gctNamc( ) : null; 

proplnfo.bound = pd.isBound( ); 

proplnfoxonstrained « pd.isConstrained( ); 

// Initialize beanlnfo data 

proplnfo.exposed - !pd.isHtdden( ); 

propInfo.displayNamc - pd.getDisplayName( ); 

proplnfo.dcscription - pd.getshaitDescription( ); 

aass prq)Editoi » pd.gctPropertyEditorclass( ); 

if (propEditoi !» null) { 
// System-err.piuitlnC* JBX DEBUG: propEditor" + 

propEditot.getName( )); 

// proplnfo .propertyEditorClass = defaultEditorString; 

propInfo.propertyEditorClass = propEditor.getName( ); 

} 

else 

propInfcpropertyEditoiClass =• defaultEditorString; 
superPropettylnf o. add(proplnf o); 

} > 

// Now find the properties that we found in the source file we're 
// working with. 

Array declaredProps - getPropertyInfoArray(jMethods); 

jb3dnfo.setSuperPropertyInfo(superPropertyIiifo); 

jbxInfo.setPropertyInfo(declaredProps); 



In operation, the readProperties method creates a proplnfo 
structure for each property descriptor returned. The read- 
Properties method sets up a loop that translates information 30 
from each property descriptor into a corresponding proplnfo 
structure. After completion of the loop, a superPropertylnfo 
array has been created, which all of the propertylnfo data 
structures from the super-class have been added to. 

By invoking getPropertylnfoArray, passing the array of 35 
methods from the source file, the readProperties method can 
determine the properties that are actually in the file that the 
system is currently working with. Internally, the system 
performs pattern matching, for determining whether some- 
thing is a property. For example, from the Java specification, 40 
every property accessor must be public and non-static, since 
it must be able to be called from outside the package. From 
this approach, the method may infer the name of the 
corresponding property. In this manner, the method may 
apply a sequence of tests for determining whether a particu- 



lar method is a property accessor method. If a property 
accessor method is located, say one called 
getAccountBalance, the method may infer that there is a 
property named accountBalance. Based on the signature for 
the accessor method, the system can determine the type of 
the property. In the case of getAccountBalance, for example, 
the accessor method (i.e., reader method) may return a type 
of integer (int). From this, the system may infer that there is 
a property, accountBalance, of type integer (int). The 
method may then later encounter the writer for the property, 
set AccountB alance . At the conclusion of the getPropertyln- 
foArray call, the system has constructed an array of 
Propertylnfo's — declaredProps — for the particular bean that 
is being designed. Now, the system may return to the caller, 
the readNode method. 

The readNode method proceeds to read the events. This is 
done by invoking the readEvents call, which may be imple- 
mented as follows. 



// Find out what event eets are declared in the superclass, and what 
event sets 

// are declared in the bean itself. 

private static void readEvents (Jbxlnfo jbxlnfo, JfotMethod[ ] jMethods, 
Beanlnfo beanlnfo) 

// First, fill the superEventMo array with the event sets that exist 
// in the superclass. 
Array supcrEventlnfo » new Array( ); 
EventsetDescriptor[ ] eds - null; 
if (beanlnfo !- null) { 
try { 

eds ° beanlnfo. getEventSetD«criptors( ); 

} 

catch (Exception ex) { 

if (ex instanceof QasstfotFoundException) { 
ex.printStackTrace( ); 

} 

} 

} 

if (eds !- null) { 

for (int i - 0; i < edsJength; i++) { 
EventSetDescriptor ed - eds[il 
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String ltstcncrPullNamc - ed.getListenerType( ).gctNamc( ); 
String packagcNamc «- 
Jo tNam w.gctPackageFromFullCJass NameQistenerFulIName); 

String listcnciNamc -> JotNamca.getShortaassName0istcnerFulINaine); 
Evcntlnfo ci - new EvcatIafb(JhxEnginccapitalizc(cd.gctNamc( )), 
packageName, 

listeneiName); 

superEventlnfo.add (ei) ; 

} 

} 

Array sourceEvents = new Array( ); 
for (int i = 0; i < jMethods.length; i++) { 

// If the method is static or no n- pub lie, skip it . . 
int mods » jMethods[i].getModifiers( ); 
if (Modifier.isStatic(mods) || ! Modifier. isPublic(mods)) { 
continue; 

} 

String type «« jMethodsfiJgetReturnTypef ).getName( ); 
// If we can't rind the type, oi the type isn't void, skip it. . . 
if (type == null j| ltype.equals( M void")) 
continue; 

Eventlnfo ei - makeEventInfo(]bxInfo, jMethods[i]); 
if (ei I- null && 1 sourccEvents .contains (ei)) { 

ei.currentSouic© - true; 

sourceEvents.add(ei) ; 

} 

} 

jbxln fo.setSuperEvents(superEventInfo); 
jbndnfo.setSourceEventa (sourceEvents); 



Operation of the readEvents method is very similar to that 
described for the readProperties method. Specifically, it 
reads in the events that are declared in the super-class and 
the events that are declared in the bean itself. Again, 
beanlnfo is employed to find all the events. Once that 
information is found, the readEvents method builds an 
eventlnfo object for each event descriptor found (from the 
Java beanlnfo object). After the method determines all the 
ones declared in the super-class, it proceeds to enumerate all 
the ones declared in the file (bean) itself. Just as the 
properties have identifiable design patterns, so do the event 
sets. Suppose, for instance, that the bean is going to be a 
source for an action event. In such a case, it will need a 
method called addActionListener and a method called 
removeActionListener (here, the methods providing a way 



for other components to add or remove themselves as 
listeners). This pattern may be used to identify the events in 
the bean. Specifically, the method may process the array of 
methods obtained from Jot (i.e., code generator), applying a 
35 pattern matching test (e.g., begins with an "add" or 
"remove" and ends with "listener"). After completing the 
readEvents processing, the system returns to the caller, 
readNode. 

40 The call to readEvents found all the events that were 
sourced. The approach for finding events that the bean is 
listening for is, however, different. To listen for an event, the 
bean must implement the particular event listener interface. 
To perform this work, the readNode method invokes 
readinterfaces, which may be implemented as follows. 



private static void readInterfaces(JhxInfo jbxlnfo, JotClassSource 
jClassSource, Node node) { 

Array listenerEvents = new Array ( ); 
Array implementedlnterfaces = new Array( ); 
JotIype[ ] jtype = jClassSource.getlnterfaces ( ); 
if (jtype 1= null) { 

for (int i - 0; i < jtypclength; i++) { 

String iName » getFullTypeQ'bxIrifo, node, jtype[i].getName( )); 

implementedInterfaces.add(iName); 

if (iName.endsWith( K Listener")) { 

String packagcName - JotNarrus.geU > ackageFromPuliaassNarne(iNarne); 
String listenerName - JolNames.getShortClassName(iName); 
int index » lis teiierName.la$UndexOf ("Listener'*); 
Eventlnfo ei - new Eventlnfo (listenerName.substring(0, index), 
packagcName, 

liatenerName); 
if (ei !- null && ! listenerEvents. contains (ei)) { 
eLcurrentListeneT - true; 
listenerEvents .add(ei); 

} 

} 



04/14/2004, EAST Version: 1.4.1 



US 6,237,135 Bl 
33 34 

-continued 



} 

} 

else 

System-cn-printinC JBX DEBUG: jtype — null"); 
j^jdnfo.sctlmplcmentedlnteifacesCimplemoitcdlDteifaccs); 
jtndnfojsetlistea&rEventsClisteiierEvents); 



In a manner similar to that described above, the readlnter- 
faces method applies a sequence of pattern-matching tests. 
Thus, the method can determine any interfaces that actually 
listen for events. After completing the processing, the sys- 
tem returns again to the caller, readNode. 

The readSpeciallnfo method may now be invoked for 
reading any special information. There are common ways to 
fire property-change events and property-vetoable events. 
These are so common that many base classes implement 
them. The readSpeciallnfo method determines whether the 
base classes specifically support that. This affects the code 
which the system generates. After completing this 
processing, the system returns again to the caller, readNode. 

The readNode method concludes by setting the name of 
the bean, setting the package name, and setting the super- 
class name. At that point, the system has initialized all the 
members in the Jbxlnfo object or structure, including all the 
propertylnfo structures and Eventlnfo structures. By prop- 
erly parsing the source code for uncovering this information, 
the call to the readNode method allows the system to be a 
two-way tool. 

Now, the UI is initialized with the two-way tools infor- 
mation. Accordingly, the user can use the two-way func- 
tionality of the system, such as adding a method, adding an 
event, or adding a property. If the user, for instance, wants 



to add a property, the system already knows exactly what 
properties are present in the bean — this information is 
maintained in the current Jbxlnfo for the bean. Upon the user 
completing a New Property user interface dialog for adding 
a property, the Jbxlnfo class's addProperty method is 
invoked. 



// Jbxlnfo worker function example... 
// Methods called by the NewFropcrty Dialog... 
public void addProperty(PropertyInfo pi, boolean override) { 

// Housekeeping... 

// Call Property Engine... 

} 



The method is invoked with a propertylnfo object, which 
was built from the information entered by the user into the 
New Property dialog. Specifically, the propertylnfo object is 
set with the particular information entered by the user, 
including the name and type for the new property. 

Based on its knowledge of existing properties in the bean 
and the super-class, the system may now generate appro- 
priate source code for adding the new property. For adding 
a property, the system invokes the Property Engine, which 
itself has an addProperty method. 



20 



25 



// PropertyEngine worker function example. . . 

static void addProperty (Jbxlnfo jbxlnfo, Node node, Propertylnfo pi, 
boolean override) 

String propertyName = pi.namc; 

String type = pi.typc; 

boolean reader *> pi.readMethod != null; 

booiean writer =■ pLwriteMethod != null; 

JotSourceFiJe srcFile = 
jbxlnfo .getPackageManager ( ).getSourceFile(((JavaSourceNode) 
node).getFilcnamc( )); 

JotClassSourcc jClassSourcc » ((JotOassSource) 
(srcFUe.getclasses( ))[0J; 

JotMethodj ] jMethods « jaassSource.getDeclaredMelhods( ); 

JotField[ ] jFields = jClassSource.getDeclaredFields( ); 

JotMarker me thodLo cation » jMethodsiength > 0 7 ((JotMarker) 
jMethodsTjMethods.length-1]) : null; 

JotMarker fleldLocation « jFields.length >0 ? ((JotMarker) 
jFietdstjFields.length-lD : null; 

String property Suffix a capitalize(propertyName); 

if (loverride) { 

// If the field name already exists with a different type, all bets 

are 

// off, so do nothing. 

JotFieldDcclaiation fieldDec - jQa8sSourcc.addFicld(fieldLocation, 
false, type, propertyName); 

if (!Validator.isFieldConflict(fteldDec, jRelds) 

// Determine whether or not to generate the field, 
if (l\^lidatori&AlreadyDeclared(fieldDec, jFields)) 
fieldDeasetModifiers(Modilier.PRIVXrE); 

} 

else 

jClassSource.removeField(fieldDec); 
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// Should we generate a reader for this property? 
if (reader) 

addReader (jbxtnfo, jClassSource, jMethods, pi, override); 
// Should we generate a writer for this property? 
if (writer) 

addWriterflbxInfo, jOassSource, jMethods, pi, override); 
if ((pi.bound || pLconstrained) && 1 jbxInfoasNativeChangeSupported( )) 



EventEngine.addPropertyaiangeSupport(jbxIiifo, srcFile, jClassSource); 
uXpLconstrained) 

EventEngiae.addVetoableChangeSupport(jbxInfo, srcFile, 

jClassSource); 

} 

jbxlnfo.updateTunestamp(srcFile, true); 
) 

The Property Engine has additional lower-level context for property. In a complementary fashion, the generated coded 
supporting actual generation of code. For example, if the 20 must subsequently fire a property-change event after setting 

code is overridden, the engine knows that it need not ^XSoperty method includes calls to helper or 

generate a storage variable, because the super-class already workef ^fo^ a ddReader and addWriter. The addWriter 

has one. Similarly, for a bound property or constrained ^ a ddReader methods are the actual methods which add a 

property, the code that is generated is somewhat different. writer and add a reader, respectively. For example, an 

For example, for a constrained property, the generated code exemplary addWriter helper function may be implemented 

must first fire a vetoable-change event before setting the as follows. 



// Add a property setter to this class 
// 

private static void addWriter(JbxInfo jbxlnfo, JolClassSource 
jClassSource, JoiMethod[ ] jMethods, Propertylnfo pi, boolean override) { 

JotMarker methodLocation - jMethods .length > 0 ? ((JotMarker) 
jMethods[jMethods.ierigth-lD : null; 

String writerName - rnakeWriterName(pi.name); 

String propertySuffix - capitalize(pLname); 

JotMethodSouroe setSource - jClassSource^ddMethod(methodLocation, 
false, "void", writerName); //NORES 

setSource.fletParameter'Iext(pi.type + " new" + propertySuffix); 

setSource.setModifier8(Modiftcr.PUBLIC); 

if (tpLbound && !pi.cons trained) { 

// Define the set<property> method. We want it to look like this. . . 

// 

// public void setSample(<type>newSample) 

// sample « newSample; 

//} 

// 

// . . . or this . . . 
// 

// public void setSample(<type>newsample) { 

// super.setSample(newSampie); 

//} 

if (override) 

setSouice.getCodeBlockf ) ^ddStatement^ull, false, "super" + 
writerName + "(new" + propertySuffix +")"); 
else 

setSource.getCodeBlock( )^ddStatement(null > false, pi.name + ** = 
new" + propertySuffix); 

else if {pi.bound [| piconstrained) { 

// Define the set<property>method. We want it to look like 
something like this . . . 
// 

// public void setS amp lc(<type>newSample) throws 
java.beans.PropertyVetoException { 

// <type>oIdSample ■=> sample; 

II fireVetoableChange("sample", oldSample, newSample); 
// sample - newSample; 

// fUePropertyChange^sample", oldSample, newSample); 
//} 

// 

// Declare the storage variable foT the aid value. We want it to 



04/14/2004, EAST Version: 1.4.1 



37 

-coatinued 



look like this. 
// 

// <typooldSamplc - sample; 
// 

// . . .or like this. . . 
// 

// <type> oldSample « super. getSample( ); 

// 

String typeObject « getdassPromPrimitivefpLtype); 
String oldObject = typeObject *=» null ? "old" + propertySuffix 
: "new" + 

getdassFromPrimitive(pi.type) + "(old" + propertySuffix + **)"; 

String newObject = typeObject == null 1 "new" + propeitySuffix 
: "new " + 

getOflssFromFrimitive(pi.type) + "(new" + propeitySuffix + ")"; 

JotVariableDeclaration jVarDec « 
setSource.getCodeBlock( ).addVariableDedaration(mjll, false, pUype, " 
old" + propertySuffix); 

if (! override) 

j VarDec.setInitializer(pLname) ; 

else 

j\^xDec^etInitializer(nTakeReaderName(pi.nanie, pLtype) + *( )"); 
if (pL constrained) { 

// Fire the PropertyChangeEvent to our vetoable listeners. Like 

so . . . 

// 

// fireVetoableChange( M sample", oldSample, newSample); 
// 

// . . . or like . . . 
// 

// vctoablcChamgeIisteneis.fireVetoableQiange("sample M , oldSample, 

newSample); 

// 

setSource.addThrowSpecijier(mill, false, 
"java.bcans.PropcrtyVetoExccption"); 

String callString = jbxInfo.isNativeChangeSupported( ) ? 
"fireVetoableChange" 

vetoableMulticaster + " .ftje Veto abl eChange" ; 

JotMethodCall vetoMethod « 
setSource.getCodeBlock( ).addMethodCall(null, false, callString, null); 

vetoMethod.addArgument(null, false, T" + pUame + "V"); 

vetoMethod.addArgument(null, false, oldobject); 

vetoMethod.addArgument(null, false, newobject); 

} 

// Assign the new value like this . . . 
// 

// sample = newSample; 
// 

// . . . or like this . . . 
// 

// super.setSainple(newSarnple); 
// 

if (loverride) 

setSourcc.gctCodeBlock( ).addStatement(null, false, piaame + " 
new" + propertySuffix); 

else 

eetSource.getCodeBlock( ).addStatement(null, false, "super."+ 
writerName + "(new" + propertySuffix + ")"); 
if (pLbound) { 

// Fire the PropertyChangeEvent to our property change iisteners. 

Like . . . 

// 

// firePropertyChangeC'sample", oldSample, newSample); 

// 

// . . . or like . . . 
// 

// propertyChangcIistencB.ru-cPropertyChange^samplc", oldSample, 

newSample); 

// 

String callString ■» jbxInfo.isNativcChangcSupported( ) ? 
**fircProp erty Change" 

property Muiticaster + ".nTePropertyChange"; 

JotMethodCall changeMethod - 
setsouice.getCodeBloci( ).addMethodCall(null, false, callString, null); 

changeMethod.addArgument(null, false, *V+ pLname + "V" 4 ); 

changeMethod. a ddArgumcnt(Dull, false, oldObject); 

changeMethod.addArgurnent(null, faise, newObject); 
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} } 

if (\felidatar.isAlrcadyDcclarcd(sctSouicc, jMethods)) 
jOass Source, rcmovcMctbod(sctSourcc); 

} 



The addWriter method may be invoked in multiple places, 
for instance, when the user has added a property that has a 
writer or modified a property to add a writer. At the outset, 
the addWriter method determines, based on the name of the 
property, what the name of the writer should be. For 
example, if the property name is accountBalance then the 
writer should be named setAccountBalance. The actual code 
that is generated depends on whether the property is 
overridden, bound, or constrained, as specified in the cor- 
responding propertylnfo structure. If the property is not 
overridden, for instance, the system has already generated a 
storage variable for it and may simply proceed to assign into 
that storage variable. Otherwise, the code must be generated 
somewhat differently. In such a case, the value of the 
property is maintained in the super-class and must be 
updated there by calling the appropriate setter method. As 
another example, in the case of a constrained property, code 
must be added to temporarily save the old value (of the 
property) and invoke a vetoable change, passing the old and 
new values (that may trigger an exception that prevents the 
property from being changed). 

While the invention is described in some detail with 
specific reference to a single-preferred embodiment and 
certain alternatives, there is no intent to limit the invention 
to that particular embodiment or those specific alternatives. 
Thus, the true scope of the present invention is not limited 
to any one of the foregoing exemplary embodiments but is 
instead defined by the appended claims. 

What is claimed is: 

1. In a system for developing computer programs, said 
programs being created, at least in part, from software 
components, a method for assisting a user with creation of 
components, the method comprising: 

providing design patterns specifying how components 
created in the system must appear when in source code 
form; 

receiving user input for creating a particular component of 
interest, said user input specifying at least one property 
to be created for the component, including specifying 
whether said at least one property should have associ- 
ated functions for setting and getting values for the 
property; 

based on said design pattern and said user input, emitting 
source code suitable for creating the particular 
component, said source code including functions for 
setting and getting values for at least one property; 

receiving a request to add a new property to the particular 
component; 

in response to said request and in response to parsing said 
emitted source code, displaying a user interface dialog 
allowing the user to specify a name and type for the 
new property for the already-created particular compo- 
nent; and 

based on said name and type for the new property, 
emitting new source code suitable for creating the 
particular component, said new source code including 
source code for creating the new property for the 
particular component. 

2. The method of claim 1, wherein said user input includes 
a user-specified name for the particular component. 



10 3. The method of claim 2, wherein the associated function 
for setting values for a property comprises a function that 
takes a parameter having a data type that is the same as that 
for the property. 

4. The method of claim 2, wherein the associated function 
15 for getting values for a property comprises a function that 

returns a value having a data type that is the same as that for 
the property. 

5. The method of claim 2, wherein the associated func- 
tions for getting and setting values each include a function 

^ name that is based, at least in part, on the user-supplied name 
for the particular component. 

6. The method of claim 1, wherein said particular com- 
ponent is a Java bean component and wherein said step of 
emitting source code includes: 

emitting a Java class suitable for creating the Java bean 
25 component. 

7. The method of claim 1, wherein said design patterns 
specify how properties, methods, and events should appear 
in source code form for components. 

8. The method of claim 1, wherein said design patterns 
30 specify how components should be packaged for re-use in 

the system. 

9. The method of claim 1, wherein said receiving step 
includes: 

receiving user input indicating whether the particular 
35 compopent should register to listen for events occurring 
at another component. 

10. The method of claim 9, wherein said step of emitting 
source code includes: 

emitting source code for indicating that the particular 
40 component should register to listen for events occurring 
at another component. 

11. The method of claim 1, wherein each component 
comprises a collection of one or more Java classes that 
serves as a self-contained, reusable component. 

4 5 12. The method of claim 1, wherein said receiving step 
includes: 

receiving user input indicating that the particular compo- 
nent should include user-specified methods. 

13. The method of claim 12, wherein said step of emitting 
50 source code includes: 

emitting at least initial source code for user-specified 
methods that the user has indicated that the particular 
component should include. 

14. The method of claim 1, wherein said source code 
comprises Java-compatible source code. 

55 15. The method of claim 1, wherein said particular 
component is a Java bean component and wherein said step 
of receiving user input includes: 

displaying a user interface dialog allowing the user to 
specify a name for the component, a package that the 
60 component will be in, and a class that the component 
will extend from. 
16. The method of claim 1, wherein said particular 
component is a Java bean component and wherein said step 
of emitting source code includes: 
65 emitting a Java class suitable for creating the Java bean 
component, wherein said Java class is declared as 
public and includes a parameterless constructor. 
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17. The method of claim 1, wherein a property's associ- 
ated function for getting values for the property returns the 
current value of the property, and wherein a property's 
function for setting values for the property sets the property 
to a new value. 

18. The method of claim 1, further comprising: 
allowing the user to specify whether the new property 

should have associated functions for setting and getting 
values for the property. 

19. In a system for developing computer programs, said 
programs being created, at least in part, from software 
components, a method for assisting a user with development 
of components, the method comprising: 

providing design patterns specifying how components 
created in the system must appear when in source code 
form; 

based on said design patterns, creating a particular com- 
ponent by emitting source code for the particular com- 
ponent; 

after creation of the particular component, receiving first 
user input requesting modification of the particular 
component of interest; 

in response to said first user input, determining from said 
design patterns and from parsing the emitted source 
code for the particular component at least one property 
of the particular component that is suitable for modi- 
fication; 

displaying a user interface dialog displaying properties of 
the particular component suitable for modification; 

receiving second user input specifying modification of a 
particular property of the particular component; and 

in response to said second user input, emitting new source 
code suitable for recreating the particular component 
with the user-specified modification of the particular 
property. 

20. The method of claim 19, wherein said first user input 
includes a user-specified selection of the particular compo- 
nent from a list of components. 

21. The method of claim 20, wherein the determining step 
includes: 

parsing the source code for identifying properties of the 
particular component. 

22. The method of claim 19, wherein the source code 
comprises Java source code. 

23. The method of claim 19, wherein said particular 
component is a Java bean component and wherein said step 
of emitting source code includes: 

emitting a new Java class suitable for modifying the Java 
bean component 

24. The method of claim 19, further comprising: 
compiling the emitted source code for recreating the 

particular component. 

25. The method of claim 19, wherein said design patterns 
specify how properties, methods, and events should appear 
in source code form for components. 

26. The method of claim 19, wherein said design patterns 
specify how components should be packaged for re-use in 
the system. 

27. The method of claim 19, wherein the modification 
specified by said second user input comprises modifying an 
existing property's type. 

28. The method of claim 19, wherein the modification 
specified by said second user input comprises deletion of an 
existing property. 

29. A development system for assisting a user with 
development of components used to create software 
programs, the system comprising: 

a parser for parsing source code for a component of 
interest which has already been previously generated in 
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source code form, for determining from the source code 
properties, events, and methods of the component; 
a user interface for displaying information relating to said 
parsing of the source code and for receiving user input 
s for changing selected ones of the properties, methods, 
and events of the component of interest; and 
a code generator for emitting new source code for the 
particular component, said new source code including 
any changes specified for the component by the user. 
10 30. The system of claim 29, wherein said parser includes 
design patterns for identifying properties, events, and meth- 
ods of the component. 

31. The system of claim 29, wherein said component 
comprises a Java bean component and wherein said source 

15 code comprises Java source code. 

32. The system of claim 29, wherein said user input for 
changing selected ones of the properties, methods, and 
events comprises user input for adding, removing, or modi- 
fying selected ones of the properties, methods, and events. 

33. The system of claim 29, further comprising: 
a code editor allowing the user to edit source code for the 

component of interest, wherein said parser is still 
capable of parsing source code that has been edited by 
the user, for determining properties, events, and meth- 
ods of the component. 

34. In a system for developing computer programs, said 
programs being created, at least in part, from software 
components, a method for assisting a user with development 

30 of components, the method comprising: 

providing design patterns allowing the system to deter- 
mine from source code any properties, methods, and 
events for a given component; 
based on said design patterns, creating a particular com- 
35 ponent of interest; 

receiving first user input requesting a change to the 

particular component of interest; 
in response to said first user input, determining from said 
design pattern and from source code for the particular 
40 component the properties, methods, and events of the 
particular component; 
displaying a user interface dialog displaying information 
about at least one of any properties, methods, and 
events of the particular component; 
45 receiving second user input specifying change of a par- 
ticular properties, methods, or events of the particular 
component; and 
in response to said second user input, emitting source 
code suitable for recreating the particular component 
50 with the user-specified change of the component. 

35. The method of claim 34, wherein said first user input 
includes a user-specified selection of the particular compo- 
nent from a list of components. 

36. The method of claim 34, wherein the determining step 
55 includes: 

parsing the source code for identifying at least some of the 
properties, methods, and events of the particular com- 
ponent. 

37. The method of claim 34, wherein the source code 
60 comprises Java source code. 

38. The method of claim 34, wherein said particular 
component is a Java bean component and wherein said step 
of emitting source code includes: 

emitting a new Java class suitable for changing the Java 
65 bean component. 
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